Cash payment for remote transactions

ABSTRACT

Methods coordinate payment for a remote transaction with a first party. An identification of the first party is received at a host system. Acknowledgment of receipt of a cash payment from a second party is received. The cash payment is associated with the identification of the first party. A money transfer corresponding to the cash payment to the control of the first party is executed with a request for the first party to perform on previously agreed terms of the remote transaction.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. Pat. No. 8,286,861, entitled“CASH PAYMENT FOR REMOTE TRANSACTIONS,” filed Aug. 23, 2011, which is acontinuation of U.S. Pat. No. 8,025,212 filed Nov. 18, 2005, entitled“CASH PAYMENT FOR REMOTE TRANSACTIONS,” which is a continuation-in-partof U.S. Pat. No. 6,994,251, filed May 22, 2003, entitled “CASH PAYMENTFOR REMOTE TRANSACTIONS,” which is a continuation-in-part of U.S. Pat.No. 6,761,309, filed Nov. 07, 2002, entitled “METHOD AND SYSTEM FORPERFORMING MONEY TRANSFER TRANSACTIONS,” which is a continuation of U.S.Pat. No. 6,488,203, filed Oct. 26, 1999, entitled “METHOD AND SYSTEM FORPERFORMING MONEY TRANSFER TRANSACTIONS.” The entire disclosures of eachof the foregoing applications and/or patents are incorporated herein byreference, for all purposes, as if fully set forth herein.

This application is also related to the following applications orpatents: U.S. Pat. No. 7,849,006 entitled “ONLINE STAGING OF AUCTIONSETTLEMENT TRANSACTIONS,” filed Mar. 27, 2003, which is acontinuation-in-part of U.S. patent application Ser. No. 10/262,529,entitled “WORLDWIDE CASH VENDOR PAYMENT,” filed Sep. 30, 2002, which isa continuation-in-part of U.S. patent application Ser. No. 10/109,559,entitled “INTERNATIONAL NEGOTIABLE INSTRUMENT PAYMENT,” filed Mar. 27,2002; and U.S. patent application Ser. No. 10/045,313, entitled“INTERNET-BASED MONETARY PAYMENT SYSTEM,” filed Oct. 24, 2001, which isa continuation of U.S. Pat. No. 7,110,978, entitled “INTERNET-BASEDMONETARY PAYMENT SYSTEM,” filed May 10, 1999. The entire disclosures ofeach of the foregoing applications and/or patents are incorporated byreference, for all purposes, as if fully set forth herein.

BACKGROUND OF THE INVENTION

This application related generally to methods and systems for executingremote transactions. More specifically, this application is related tomethods and systems for executing remote transactions with cash payment.

In recent years, there has been a steady increase in the number oftransactions performed remotely. Such transactions typically take placebetween a merchant and a customer who are remote from each other. Forexample, transactions for the sale of goods are now frequently executedbetween the merchant and customer by telephone, over the World Wide Web(“WWW”), or through another remote mechanism. Currently, such remotetransactions are generally effected through the use of an account-basedpayment vehicle, such as with a credit card, a debit card, or a check.In some instances, an account-based surrogate for one of these vehiclesmay be used. For example, the Paypal® system sets up accounts thatreceive funds from a customer's credit, checking, or other traditionalfinancial account, and uses these new accounts to provide payment fortransactions. The use of such surrogate accounts is intended to helpshield the underlying traditional financial-account information, but itstill must at least be disclosed to the Paypal® system.

Various other security mechanisms also exist when transactions areperformed remotely to limit the incidence of fraud, such as through theuse of encryption of information when such information is transmittedelectronically. The need for such security mechanisms is a reflection ofthe general fact that there is a significantly higher risk of fraud forremote transactions because the payment vehicle is not physicallypresent during the transaction. In particular, these remote transactionsrely on transmission of the account information from the customer, suchas over the telephone or through a WWW interface, rather than extractingthe information directly from the magnetic strip on a credit or debitcard, for example. The increased risk of fraud in such remotetransactions is reflected in the higher cost that must be borne by themerchant in the form of charges imposed by the financial institutionthat provides the payment vehicle. In most instances, higher costs areimposed whenever a transaction is performed without the instrumentcompared with performing the transaction with the instrument. Inaddition to restraining merchant participation in remote transactions,this risk of fraud is also well known to be a significant factorinhibiting customers from performing remote transactions.

These risks result in a large number of legitimate transactions nottaking place as customers and/or merchants attempt to mitigate the riskof fraud. There is, accordingly, a general need in the art for improvedmethods and systems for executing remote transactions.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention use coordination of a money-transfer systemwith a merchant transaction system to permit remote transactions withthe merchant to be effected with cash or with noncash instruments. Acustomer making use of the service to pay for part or all of a remotetransaction with the merchant begins by arranging for the transactionwith the merchant, indicating the desire to pay in cash, and receiving amoney-transfer transaction identifier. The customer may then visit alocal branch of the money-transfer system, pay in cash for thetransaction, and expect that the merchant will be advised of the paymentand initiate execution of its obligations in accordance with thetransaction.

Thus, in one set of embodiments, a method is provided for executing aremote transaction between a merchant and a customer. A designation of amonetary amount for the remote transaction and an identification of themerchant are transmitted from a merchant processing system to a hostsystem controlled by a money-transfer provider. A money-transfertransaction identifier identifying a prepared money-transfer transactionfor transfer of the monetary amount is established at the merchantprocessing system. The money-transfer transaction identifier is providedto the customer. Performance of merchant obligations in accordance withthe remote transaction is initiated after notification to the merchantprocessing system of receipt of a cash payment made by the customertowards the prepared money-transfer transaction.

Establishment of the money-transfer transaction identifier may includereceiving the identifier from the host system or may include agreeing tothe identifier with the merchant and customer. In some such embodiments,the method may further comprise notifying the customer of an amount ofthe cash payment to be made to the money-transfer provider. The amountof the cash payment may be greater than the monetary amount. Initiationof performance obligations may be performed after transfer of themonetary amount by the money-transfer provider to the control of themerchant. Notification of the transfer could be received, for example,from the host system or from a financial institution holding themonetary amount on behalf of the merchant. The notification could bereceived substantially contemporaneously with the transfer of themonetary amount. In some cases, the financial institution holding themonetary amount on behalf of the merchant could be the money-transferprovider. In some instances, the remote transaction comprises a sale ofa product from the merchant to the customer; initiating the performanceof merchant obligations in such instances may comprise initiatingshipment of the product to the customer. In other embodiments, themethod may further comprise receiving, at the merchant processingsystem, a notification that the money-transfer transaction has beeneffected. Such a notification may be received from the host system.Alternatively, receiving such a notification may comprise receiving anacknowledgment of receipt of the monetary amount by a financialinstitution.

These methods may be embodied in a computer-readable storage mediumhaving a computer-readable program embodied therein for directingoperation of the merchant processing system. The merchant processingsystem may include a processor, a storage device, and a communicationssystem. The computer-readable program includes instructions foroperating the merchant processing system to execute a remote transactionin accordance with the embodiments described above.

In another set of embodiments, a method is provided for coordinatingpayment for a remote transaction between a merchant and a customer. Adesignation of a monetary amount for the remote transaction and anidentification of the merchant are received at a host system from amerchant processing system. A money-transfer transaction identifier istransmitted from the host system to the merchant processing system toidentify a prepared money-transfer transaction for transfer of themonetary amount. Thereafter, acknowledgment of receipt of a cash paymentassociated with the money-transfer transaction identifier is received atthe host system. The prepared money-transfer transaction is effected bytransferring the monetary amount to the control of the merchant.

In some embodiments, the merchant processing system is notified that thepotential money-transfer transaction has been effected. Receipt of thedesignation of the monetary amount and transmission of themoney-transfer transaction identifier may be performed over theInternet. In one embodiment, the cash payment is greater than themonetary amount.

In a further set of embodiments, a method is provided for coordinatingpayment for a remote transaction with a first party. An identificationof the first party is received at a host system. Acknowledgment ofreceipt of a cash payment from a second party is received. The cashpayment is associated with the identification of the first party. Amoney transfer corresponding to the cash payment to the control of thefirst party is executed with a request for the first party to perform onpreviously agreed terms of the remote transaction.

In some of these embodiments, the identification of the first party maycomprise a money-transfer transaction identifier associated with thefirst party. Receiving acknowledgment of receipt of a cash payment fromthe second party may comprise receiving acknowledgment of receipt of aplurality of cash payments over a period of time. For example, each ofthe plurality of cash payments may be made by the same second party ormay be made by different second parties. In one embodiment, each of theplurality of cash payments is for an amount less than a transactionamount identified by the previously agreed terms of the remotetransaction to require performance by the first party on the remotetransaction. Executing the money transfer may thus comprise executingthe money transfer for at least the transaction amount after receivingsufficiently many of the plurality of cash payments that an aggregateamount of the sufficiently many of the plurality of cash payments isequal to at least the transaction amount. Alternatively, executing themoney transfer may instead comprise executing the money transfer for oneof the plurality of cash payments for the amount less than thetransaction amount. In one embodiment, the remote transaction comprisesa standing order, with one of a plurality of money transfers beingexecuted after receipt of a respective one of the plurality of cashpayments with a request for the first party to fulfill the standingorder.

In a specific embodiment, a method is provided for coordinating paymentfor a remote transaction with a first party. An identification of thefirst party is received. Acknowledgment of receipt of a first cashpayment from a first second party is received. The first cash payment isassociated with the identification of the first party. A first moneytransfer corresponding to the first cash payment is executed to thecontrol of the first party. Acknowledgment of receipt of a second cashpayment from a second-second party later in time than the first cashpayment is received. The second-second party is different from the firstsecond party. The second cash payment is associated with theidentification of the first party. A second money transfer correspondingto the second cash payment is executed to the control of the secondparty. A request for the first party to perform on previously agreedterms of the remote transaction is transmitted.

In another specific embodiment, a method is provided for coordinatingpayment for a remote transaction between a first party and a secondparty. An identification of the first party is received. Acknowledgmentof receipt of a first cash payment from the second party is received.The first cash payment is associated with the identification of thefirst party. A first money transfer corresponding to the first cashpayment is executed to the control of the first party. Acknowledgment ofreceipt of a second cash payment from the second party later in timethan the first cash payment is received. The second cash payment isassociated with the identification of the first party. A second moneytransfer corresponding to the second cash payment is executed to thecontrol of the first party. A request for the first party to perform onpreviously agreed terms of the remote transaction is transmitted.

These methods may be embodied in a computer-readable storage mediumhaving a computer-readable program embodied therein for directingoperation of the host system. Such a host system may include aprocessor, a storage device, and a communications system. Thecomputer-readable program includes instructions for operating the hostsystem to coordinate payment for a remote transaction in accordance withthe embodiments described above.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings wherein like reference numerals are usedthroughout the several drawings to refer to similar components. In someinstances, a sub-label is associated with a reference numeral andfollows a hyphen to denote one of multiple similar components. Whenreference is made to a reference numeral without specification to anexisting sub-label, it is intended to refer to all such multiple similarcomponents.

FIG. 1A is a block-diagram representation of an arrangement forperforming remote transactions in accordance with an embodiment of theinvention;

FIG. 1B is a schematic representation of an embodiment of a method forperforming remote transactions using the arrangement shown in FIG. 1A;

FIG. 2A is a flow diagram illustrating embodiments for executing remotetransactions and coordinating payment for remote transactions;

FIG. 2B is a flow diagram illustrating embodiments in which multipleremote payments are made for a transaction;

FIG. 2C is a flow diagram illustrating embodiments in whichstanding-order transactions are executed; and

FIG. 3 is a schematic illustration of a host system or merchantprocessing system on which methods of the invention may be embodied.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention provide methods and systems for executingremote transactions and for coordinating payment for remotetransactions. As used herein, a “remote transaction” refers to anexchange of value among at least two physically separated parties.Usually, the physical separation of the parties requires that theyinteract through a communications device such as a telephone network,computer network, or the like. Such interaction may take place directlybetween the parties, or may take place with a human or machinerepresentative of one or more of the parties. The machine representativecould be a computer system programmed to implement policies of one ofthe parties in a transaction, some examples of which are discussedbelow. For example, the remote transaction may comprise a sale of goodsand/or services in which the buyer and seller are in differentgeographical locations. In some instances, the seller may be a merchantseller, who may be represented by a telephone service representative whotakes orders from customers or who may be represented by a suitablyprogrammed merchant processing system accessible to the buyer over thean Internet, telephone, cable, or other network. In some embodiments,the methods and systems of the invention permit the execution of thetransaction by at least one of the parties to be performed with cashdespite the physical separation of the parties. As used herein, “cash”is intended to be construed to encompass cash equivalents, and thereforeincludes currency, banknotes, a generally endorsed negotiableinstrument, and the like.

A structural overview of a system in accordance with an embodiment ofthe invention is provided in FIG. 1A. This example is providedspecifically for an embodiment in which the remote transaction is totake place between a customer and a merchant, but it will be evident tothose of skill in the art that the structural arrangement may begeneralized to accommodate remote transactions between any types ofparties. Thus, as used herein, a “merchant” is intended to refer to anyparty who is to receive a payment as part of a transaction executed witha customer, and could include a lender or other such party in additionto including a seller. The customer 100 may interact with the merchantusing a variety of different interface mechanisms, some of which areshown explicitly in FIG. 1A. The manner in which the merchant iscontacted may, in some instances, differ depending on the type ofinterface mechanism that is used. For example, in one embodiment, theinterface mechanism is provided with the Internet 108 so that thecustomer may interact directly with the merchant processing system 116using a PC, PDA, laptop, or other computational device equipped toconnect to the Internet 108. In this embodiment, the merchant processingsystem 116 also comprises a computational device equipped to connect tothe Internet, and having programming as described further below toimplement embodiments of the invention.

In other embodiments, a cable interface 112 or telephone interface 104may be used for the customer 100 to interact directly with the merchantprocessing system 116. In the case of a telephone interface 104, directinteraction between the customer 100 and merchant processing system 116may use a DTMF decoder comprised by the telephone interface 104. Such aDTMF decoder permits the customer 100 to use touch-tone commands on alocal telephone to interact with the merchant processing system 116. Itmay be convenient to accommodate the limitations of DTMF tones by usinga menu-driven interface. The use of a telephone interface 104 may beespecially suitable in direct-response applications where the customerresponds almost immediately to seeing or hearing an advertisement. Inother embodiments, the interaction between the customer 100 and themerchant processing system 116 may be indirect. For example, thetelephone interface 104 could instead be configured for routing of voicesignals to a human customer-service representative. The customer-servicerepresentative would then input data to the merchant processing system116 with an input device such as a keyboard, mouse, light pen, etc. inresponse to communications with the customer 100. In addition, otherembodiments of the invention may make use of a mail-order service 114 inwhich print media may be used in interacting with the merchantprocessing system 116.

The system also includes a networking capability for the merchantprocessing system 116 to interact with a money-transfer system 124. Evenin embodiments where the customer 100 interacts with the merchantprocessing system through means other than the Internet 108, thisinteraction may take place through the Internet 108, although this isnot required. More generally, any suitable networking configuration maybe used to provide interaction between the merchant processing system116 and the money-transfer system 124, including through the use ofdedicated networks, a phone network, a wide-area network, a local-areanetwork, a wireless network, and the like. The same or a differentnetwork may also be used to provide the merchant processing system 116and/or money-transfer system 124 with the ability to exchangeinformation with financial institutions 120. In the illustratedembodiment, the financial institutions are shown interfaced with theInternet 108, as well as having direct communications with themoney-transfer system. The dashed line between the merchant processingsystem and a particular one of the financial institutions 120-1indicates that the merchant may hold an account at that financialinstitution 120-1. As explained below, the funds received by themerchant as a result of the transaction with the customer 100 mayultimately be provided to the account at financial institution 120-1.While for purposes of illustration only a single merchant processingsystem 116 is shown in FIG. 1A, the system may more generally comprise aplurality of merchant processing systems associated with a plurality ofmerchants. The plurality of merchant processing systems are integratedwithin the system in the same fashion as the illustrated merchantprocessing system 116, thereby providing the plurality of merchants withthe ability to participate in remote transactions that use cash paymentsby customers. Because the communications among the customer 100,merchant processing system 116, and money-transfer system 124 mayinvolve sensitive financial data, it may be desirable to secure thedata, such as by encrypting it before transmission.

The money-transfer system 124 itself may comprise a networkedarrangement, with interactions with the Internet 108 or other network,financial institutions 120, and/or merchant processing systems 116 beingcoordinated through a host system 128. Advantageously, themoney-transfer system 124 may be configured to permit interactionbetween the host system 128 and a large number of money-transfer branchservers 136. In such an embodiment, the money-transfer branch servers136 may be associated with local branches of the money-transfer system124 that may be visited by customers. The money-transfer branch servers136 may communicate with the host system 128 through zero or more localmoney-transfer servers 132, each of which is configured for coordinatingportions of the money transfers handled by the system. For example,branch servers 136-1, 136-2, and 136-3 communicate with the host system128 through local server 132, but branch servers 136-4, 136-5, and 136-6communicated with the host system 128 directly. Usually themoney-transfer branches will offer a variety of different money-transferservices and are not limited to providing services to support remotetransactions between merchants and customers. Moreover, in someinstances, the branches may additionally offer a variety of unrelatedservices, such as in cases where the money-transfer branches are locatedat convenience stores, supermarkets, and the like. In addition, it isadvantageous when the number of such branches is sufficiently large toprovide significant coverage of selected geographic areas. Such coveragepermits convenient access to the money-transfer system 124 by customersliving or working in the selected geographic areas—greater geographiccoverage thus corresponds to a greater accessibility by more customers.In FIG. 1A, access of the money-transfer system 124 by the customer 100is performed at a money-transfer branch server 136 and indicatedschematically with the dashed-line customer block 100.

FIGS. 1B and 2 depict the implementation of remote transactions that usethe arrangement shown in FIG. 1A. As will be evident from the followingdiscussion, both cash and noncash remote transactions may beaccommodated with the structure of FIG. 1A. FIG. 1B schematically showsthe flow of interactions between different components of the systemwhile FIG. 2A provides a flow diagram that details specificimplementations in different embodiments. The vertical lines in FIG. 1Bcorrespond to some of the blocks in FIG. 1A and the arrows in FIG. 1Bcorrespond to blocks in the flow diagram of FIG. 2A. The followingdescription thus makes reference to both FIGS. 1B and 2A simultaneously.

As indicated at block 204, a remote transaction between a merchant and acustomer may begin with establishment of contact between the customer100 and a remote-merchant processing system 116. Such contact may beestablished solely through an automated interface such as describedabove for an Internet interface, DTMF interface, cable interface, andthe like. Such contact may also be established at least partially with ahuman intermediary such as in the form of a customer-servicerepresentative. At block 208, the customer and merchant arrange forexecution of a transaction. For example, in one embodiment thetransaction corresponds to the purchase of goods from the merchant overthe Internet 108. In such an embodiment, the merchant processing system116 is configured to provide access to product information over theInternet 108 and an interface to collect customer selections. After thecustomer has confirmed selections, the merchant processing system 116may calculate the total amount due, including any taxes, servicecharges, delivery charges, and the like. In another embodiment, thetransaction corresponds to the purchase of goods from a paper catalogue.In such an embodiment, the customer 100 telephones a customer-servicerepresentative to request a purchase of goods that he has selected fromthe paper catalogue, indicating to the representative such factors asmodel numbers, colors, quantities and the like. This information isprovided to the merchant processing system 116 by the representative,such action taking the place of the automatic collection of suchinformation in the Internet-based example. These two examples aresometimes referred to in the following description to illustrateapplication of the methods in a specific context, but it should beappreciated that these examples are not intended to be limiting and thatthe methods of the invention may also be applied to other types ofremote transactions in other embodiments.

At block 216, the customer may be provided with the opportunity toselect one of a plurality of different types of payment, such as acredit-card payment, debit-card payment, check payment, and cashpayment. Such a choice may be conveyed directly to the customer 100 bythe merchant processing system 116 or through the customer-servicerepresentative in different embodiments. If the customer 100 selects anoncash payment type, account information is collected at block 252.Such account information is associated with the noncash payment type andmay identify, for example, a credit-card number, a debit-card number, achecking-account number, etc. In some instances, collection of theaccount information may be accompanied with collection of verificationinformation, such as name associated with the account, expiration dateof a credit or debit card, verification code printed on a credit ordebit card, and the like. A request for authorization of the transactionis presented to the financial institution responsible for the account atblock 256, such as by transmitting the collected account information andtransaction amount over a financial network or securely over theInternet 108 to that financial institution.

If the financial institution returns an authorization code, as tested atblock 260, the transaction may be executed with the noncash instrumentat block 272. In particular, the amount of the transaction is charged tothe credit card, debit card, or checking account, and the merchantprocessing system 116 provides instructions to initiate shipment of thepurchased goods to the customer 100. If the transaction is denied, asindicated through return of a non-authorization code, the customer 100may still be offered the opportunity to execute a cash transaction. Ifthe customer 100 does elect at block 264 to proceed with a cash payment,the method may proceed in the same fashion as if a cash payment wereelected at block 216. If the customer 100 decides against making a cashpayment after the noncash payment has been refused, the transaction isdeclined by the merchant processing system 116 at block 272.

It is also noted that in some embodiments, multiple types of paymentsmay be made for a single transaction. For example, it is possible that aportion of the transaction cost is paid with cash and a portion is paidwith a noncash instrument. The cash portion of such a hybrid transactionis executed as described below and the noncash portion is executed bycollecting account information and requesting a transactionauthorization as described above. Furthermore, some transactions maybegin as hybrid transactions, but be converted to purely cashtransactions should a non-authorization code be returned for the noncashportion of the transaction and the customer 100 indicate a desire toperform that portion of the transaction also in cash. Also, the noncashportion of any transaction, whether a purely noncash transaction or ahybrid transaction, may be made with multiple types of noncashinstruments. For example, a portion of the transaction could be madewith a credit card and a portion of the payment could be made with adebit card.

Once a determination has been made to proceed with a cash payment forthe remote transaction, either as an initial choice by the customer 100at block 216 or as an alternative choice by the customer 100 at block264, interaction with the money-transfer system 124 is invoked tocomplete the transaction. Thus, at block 220, the merchant processingsystem 116 transmits transaction information that includes a monetaryamount and an identification of the merchant to the host system 128. Inmost instances, the monetary amount corresponds to the amount requiredto complete the transaction, but in some instances it may differ. Forexample, in cases of hybrid transactions where a portion of thetransaction is executed with a noncash instrument while the remainder isexecuted with cash, the monetary amount could correspond to the portionof the transaction to be executed in cash.

The merchant identification may be, for example, a numeric oralphanumeric identifier assigned by the money-transfer system 124 andwhich identifies where funds are to be transferred in order to be placedunder the control of the merchant. In the example shown in FIG. 1A,financial institution 120-1 is used by the merchant to receive fundstransferred by the money-transfer system 124. Accordingly, the merchantidentification is associated in records maintained by the host system128 with a particular account maintained on behalf of the merchant atfinancial institution 120-1.

In response to the request from the merchant processing system 116, thehost system prepares a money-transfer transaction for the monetaryamount. This prepared money-transfer transaction specifies that uponreceipt of a certain amount of funds, the monetary amount will betransferred to control of the merchant, such as into the account of thefinancial institution 120-1 identified from the merchant identifier. Aspart of this preparation, a money-transfer transaction identifier isestablished to identify this prepared money-transfer transaction.Establishing the money-transfer transaction identifier may be performedin a number of different ways in different embodiments. In someinstances, the money-transfer transaction identifier is generated by thehost system and returned to the merchant at block 224. In otherinstances, the money-transfer transaction identifier comprises anytransaction identifier that ties the corresponding money transfer to thetransaction and is agreed to by the customer and merchant, as indicatedat block 226. For example, the money-transfer transaction identifiercould be an order number, the customer's telephone number, or any othersuitable identifier. In some embodiments, the money-transfer transactionidentifier is returned to the merchant processing system 116.

At block 228, the merchant notifies the customer 100 of themoney-transfer transaction identifier. Such notification may ofteninclude a notification of the total amount that the customer 100 willneed to provide in order to effect the cash transaction. Often thisamount exceeds the monetary amount to be transferred by themoney-transfer system 124 to reflect imposition of a fee for theservices of the money-transfer system 124. The amount of this fee couldbe a fixed amount to accommodate any cash transaction for the merchantso that the merchant processing system 116 automatically adds the fixedamount to the amount to be transferred before notifying the customer100. In other instances, the fee could vary depending on such factors asthe size of transaction, whether there are currency conversions to beincluded, where the money transfer effected by the money-transfer system124 is to be initiated, and the like. In such instances, the fee couldbe computed by the host system 128 and transmitted to the merchant bythe host system 128 with the money-transfer transaction identifier; themerchant processing system 116 could then subsequently add the fee tothe amount to be transferred before notifying the customer of the totalamount that will be due. In still other embodiments, the customer mightnot be informed of the precise fee to be charged for the money-transferservice, learning its amount only upon visiting a branch of themoney-transfer system 124 to make the cash payment.

At block 232, the customer pays in cash at one of the branches of themoney-transfer system 124. Such a cash payment may be for the entiretransaction or may be for a portion of the transaction. The advantage ofhaving a plurality of such branches is evident at this point in theprocess since the extent of geographical coverage by the branches isdirectly related to the convenience with which the customer 100 mayaccess a branch to effect payment. In some embodiments, collection ofthe funds may be performed by a clerk at the branch, although suchcollection may also be performed in a more automated fashion with akiosk or other self-service device. For example, at a branch having aclerk, the customer 100 might provide the money-transfer transactionidentifier to the clerk, who inputs it into the money-transfer branchserver 136. The money-transfer branch server 136 sends a query throughthe network of the money-transfer system 124 to the host system 128 todetermine the amount to be collected for the prepared money-transfertransaction. This amount may be displayed to the clerk, who collects theamount from the customer 100, and who then inputs an acknowledgment ofits collection to the money-transfer branch server 136. A similarprocess may be followed when the customer 100 uses a self-servicedevice. An input device such as a keypad may be provided on theself-service device for the customer 100 to enter the money-transfertransaction identifier; an output device such as a display screen may beprovided to indicate the amount of funds to be provided; and a cashacceptor may be provided to receive cash payments from the customer.Such a self-service device may be integrated with or in communicationwith the money-transfer branch server 136 so that queries and responsesto the host system 128 to identify the prepared money-transfertransaction may be performed in the same fashion as when a clerkinteracts with the customer 100.

In some embodiments, hybrid transactions that use cash for a portion ofthe transaction and a noncash instrument for the remainder of thetransaction may be accommodated entirely with the customer's interactionwith the money-transfer branch. In such embodiments, the cash portion ofthe transaction may be processed as described above. The noncash portionmay be processed by collecting account information with themoney-transfer branch server 136, either through a clerk or directlywith a self-service device. In embodiments that use a self-servicedevice, the self-service device may comprise a magnetic-strip reader, asmart-card reader, a bar-code reader, a magnetic-ink character reader,an optical reader, or other suitable device for reading informationdirectly from an instrument that may be presented by the customer 100 toeffect the noncash portion of the transaction. In embodiments that donot use a self-service device, a point-of-sale device having suchcapabilities may be provided at the money-transfer branch for use by theclerk or customer in effecting the noncash portion of the transaction.Examples of devices that include multiple capabilities for extractinginformation from such instruments are provided in the followingapplications or patents, the entire disclosures of which areincorporated herein by reference for all purposes: U.S. Prov. Pat. Appl.No. 60/147,889, entitled “INTEGRATED POINT OF SALE DEVICE,” filed Aug.9, 1999; U.S. Pat. No. 6,547,132, entitled “POINT OF SALE PAYMENTSYSTEM,” filed Aug. 9, 2000; U.S. Pat. No. 7,600,673, entitled “SYSTEMSAND METHODS FOR PERFORMING TRANSACTIONS AT A POINT-OF-SALE,” filed Apr.3, 2002; U.S. Pat. No. 6,886,742, entitled “SYSTEMS AND METHODS FORDEPLOYING A POINT-OF-SALE SYSTEM,” filed Apr. 3, 2002; U.S. Pat. No.6,827,260, entitled “SYSTEMS AND METHODS FOR UTILIZING A POINT-OF-SALESYSTEM,” filed Apr. 3, 2002; and U.S. Pat. No. 7,086,584, entitled“SYSTEMS AND METHODS FOR CONFIGURING A POINT-OF-SALE SYSTEM,” filed Apr.3, 2002.

Once the money-transfer branch server 136 has confirmation of receipt ofcash for the cash transaction, either through receipt from aself-service device or through receipt of an indication from a clerkthat it has been received, an acknowledgment of its receipt istransmitted from the branch server 136 to the host system 128 at block236. Receipt of the acknowledgment by the host system 128 prompts thehost system 128 to effect a transfer of funds in accordance with theprepared money-transfer transaction. The amount transferred may be lessthan the amount received from the customer 100 to reflect retention ofthe service charge by the money-transfer system 124. Thus, at block 240,the host system notifies the merchant that the funds have been receivedfrom the customer 100. In some instances, such a notification may bemade substantially contemporaneously with the actual transfer of funds.Receipt of such a notification prompts the merchant processing system116 to initiate completion of the transaction at block 244, such as byissuing instructions to perform merchant obligations to package and shipthe goods purchased by the customer 100 in accordance with thetransaction. At block 248, the host system 128 initiates a transfer offunds to the control of the merchant, such as by transferring funds tothe merchant's account at financial institution 120-1. Effecting such atransfer may be performed in a variety of different ways in differentembodiments. For example, the transfer could be effected by sending adebit instruction to a financial institution having funds controlled bythe money-transfer system 124 and sending a credit instruction tofinancial institution 120-1, could be effected using an automatedclearing house (“ACH”), could be effected by generating a negotiableinstrument such as a check, and the like.

The order of the blocks shown in FIG. 2A is merely exemplary, and thecorresponding functions could be performed in a different order in avariety of alternative embodiments, or some of the functions could beperformed simultaneously. For example, the initiation of the fundstransfer by the host system 128 to the control of the merchant at block248 could be performed before, after, or simultaneously with thenotification to the merchant processing system 116 at block 240. Inembodiments where it is performed after, the notification could furtherspecify that the funds have been successfully transferred to the controlof the merchant. In other alternative embodiments, the notificationcould instead be provided by financial institution 120-1 that the fundshad been received.

In some embodiments, multiple partial cash payments may be made toprovide funds for performing the transaction. Such embodiments areillustrated with the flow diagram of FIG. 2B, and may be useful in suchapplications as providing a mechanism for layaway payments for apurchase and/or for having multiple different parties contribute towardsa purchase. Further aspects of having contributions from multipledifferent parties are described in U.S. Pat. No. 7,225,154, entitled“METHODS AND SYSTEMS FOR COORDINATING POOLED FINANCIAL TRANSACTIONS,”filed Mar. 17, 2003, the entire disclosure of which is incorporatedherein by reference for all purposes.

The flow diagram of FIG. 2B emphasizes that the parties to suchtransactions need not be in a merchant/customer relationship, but may beany remote parties wishing to execute a transaction that has a cashcomponent. Aspects of the method described in connection with FIG. 2Amay thus be incorporated into the method, with the flow diagrambeginning at block 274 when the transaction processing system transmitstransaction information to a money-transfer host system. Suchtransaction information generally includes an identity of a first partyto the transaction and may additionally include a designation of a totalmonetary amount to be used in supporting the transaction. In someembodiments, the transaction information may include a money-transfertransaction identifier to be used in identifying the transaction,although other mechanisms may alternatively be used to identify specifictransactions.

Funds to be used in support of the transaction may be supplied in cashby one or more second parties. In some instances, a portion of the totaltransaction cost may be paid through other mechanisms, either at thetime the transaction is arranged or at the time one of the multiplepayments is made. Aspects of including multiple payment mechanisms aredescribed more fully above in connection with FIG. 2A. As indicated atblock 275, a person who is to make a cash payment visits amoney-transfer branch. The person makes the cash payment for a portionof the transaction less than its total amount at block 276, and thispayment is matched with the transaction information at block 277. Inembodiments where a money-transfer transaction identifier was provided,such matching may comprise receiving an indication of the money-transfertransaction identifier from the person making the payment and matchingthat with a list of outstanding money-transfer transaction identifiers.Other methods that may be used to make the match may include using thename of the first party and/or one of the second parties to thetransaction, or any other information that may uniquely identify thetransaction information.

A check is made after the cash payment is matched with the transactioninformation whether the transaction criteria have been met, as indicatedat block 278. Usually, meeting the transaction criteria includes havingreceived payment that equals or exceeds the transaction amount. Inembodiments where multiple cash payments are made before the transactioncriteria are met, the method will loop at least once back to block 275,where another person visits the money-transfer branch to make anadditional cash payment. In some embodiments, this person may be thesame person who made a prior payment, such as in embodiments wherepayment for a transaction is being made in cash on a layaway basis. Inother embodiments, this person may be a different individual, such as inembodiments where multiple parties contribute to payment for thetransaction.

Once the transaction criteria have been met, the transaction processingsystem is notified at block 279 that performance by the first party onthe transaction should be initiated. Funds collected to support thetransaction are transferred to the control of the first party at block280. While such transfer is identified at the end of the flow diagram ofFIG. 2B, this represents only one of several possibilities for effectingthe funds transfer. In some embodiments, like the one illustratedexplicitly in the drawing, the total funds needed to support thetransaction are transferred only after they have all been collected. Inother embodiments, the funds may be transferred at different intervals,such as in embodiments where funds corresponding to each of the cashpayments are transferred shortly after receipt of the cash payments. Instill other embodiments, the funds may be transferred periodically, suchas on the first business day of each month. Such embodiments areadvantageous in circumstances where payments are both made over time,such as in implementing a layaway scheme, and made by multiple secondparties—each of the second parties making payments may make a payment atdifferent times during the periodic cycle, with the full payment forthat cycle being transferred to the first party at the end of the cycle.

An illustration of embodiments in which standing orders may beimplemented is provided with the flow diagram of FIG. 2C. When astanding-order arrangement is established between parties, thetransaction processing system may transmit information about thearrangement to the money-transfer host system at block 285. Suchinformation may include details identifying the first party to whompayments are to be made to trigger performance on the standing-orderarrangement, amounts that may be required, and the like. In someembodiments, this information includes a series of money-transfertransaction identifiers that are to be used to effect individualtransfers based on cash payments.

As in other embodiments, a person thus visits a money-transfer branchoffice at block 286. This person may be the second party to thestanding-order arrangement or may be another person who makes paymentsas part of a multi-person arrangement. The person makes cash payment forthe order at block 287 and the cash payment is matched with thestanding-order information. In some instances, a match need not be madewith all of the standing-order information, but only with that portionof the information used in prompting performance on the order. This maybe the case, for instance, where the standing-order informationcomprises a plurality of money-transfer transaction identifiers, inwhich case the match may be based on a particular one of the identifiersbeing provided by the person making the cash payment. A request forperformance on the order is accordingly transmitted to the transactionprocessing system at block 289 and funds for performance on the orderare transferred at block 290.

Embodiments that make use of standing orders may advantageously findapplication in relationships between a manufacturer and a supplier. Themanufacturer may need supplies on a periodic basis from the supplier andmay use cash for transactions. Upon arrangement of a standing order forsupplies, the supplier may provide the transaction processing systemwith a series of money-transfer identifiers. Each month, themanufacturer would then visit a money-transfer branch, supply one of themoney-transfer identifiers, and make a cash payment. The money-transferidentifier would be used to effect a money transfer to the supplier andto notify the supplier that delivery of supplies should be made. In someinstances, different money-transfer identifiers could be associated withdifferent supplies so that variations in orders could be implemented byselection of appropriate identifiers. In addition, other terms may beapplied to the orders, such as by combining the method outlined in FIG.2C with the method shown in FIG. 2B so that multiple payments may bemade, with performance only being initiated when the total paymentexceeds a certain level. Excess payments could act as balances to beapplied to the next order.

FIG. 3 provides a schematic illustration of a structure that may be usedto implement the merchant processing system 116 and/or host system 128.While the structure of the merchant processing system 116 and hostsystem 128 are not generally expected to be identical, either or both ofthem may be implemented using computer systems having some or all of thefollowing components. FIG. 3 broadly illustrates how individual systemelements may be implemented in a separated or more integrated manner.The computer system is shown comprised of hardware elements that areelectrically coupled via bus 326, including a processor 302, an inputdevice 304, an output device 306, a storage device 308, acomputer-readable storage media reader 310 a, a communications system314, a processing acceleration unit 316 such as a DSP or special-purposeprocessor, and a memory 318. The computer-readable storage media reader310 a is further connected to a computer-readable storage medium 310 b,the combination comprehensively representing remote, local, fixed,and/or removable storage devices plus storage media for temporarilyand/or more permanently containing computer-readable information. Thecommunications system 314 may comprise a wired, wireless, modem, and/orother type of interfacing connection and permits data to be exchangedwith the Internet, DTMF processor, cable processor, financialinstitutions 120, local money-transfer servers 132, and/ormoney-transfer branch servers 136 as described in connection with FIGS.1A-2.

The computer system also comprises software elements, shown as beingcurrently located within working memory 320, including an operatingsystem 324 and other code 322, such as a program designed to implementmethods of the invention. It will be apparent to those skilled in theart that substantial variations may be made in accordance with specificrequirements. For example, customized hardware might also be used and/orparticular elements might be implemented in hardware, software(including portable software, such as applets), or both. Further,connection to other computing devices such as network input/outputdevices may be employed.

Thus, having described several embodiments, it will be recognized bythose of skill in the art that various modifications, alternativeconstructions, and equivalents may be used without departing from thespirit of the invention. Accordingly, the above description should notbe taken as limiting the scope of the invention, which is defined in thefollowing claims.

1. A method for coordinating payment for a remote transaction with a first party, the method comprising: receiving, at a host system, an identification of the first party; receiving, at the host system, acknowledgment of receipt of a payment from a second party; associating, with the host system, the payment with the identification of the first party; executing, with the host system, a money transfer corresponding to the payment to the control of the first party; and notifying the first party to provide a good or service according to agreed terms of the remote transaction. 